For coherent and consistent operation, a data and command bus between otherwise disparate or independent remote elementsxe2x80x94required to interact through exchange of data, interrogation and command or instructionsxe2x80x94generally follows a prescribed behaviour pattern or protocol.
Protocol
The term xe2x80x98protocolxe2x80x99 is used herein to embrace a regime, or rule set, for regulatingxe2x80x94in relation to communications traffic over a data highway or pathwayxe2x80x94the nature of inter-connection or interface, the manner of interaction, and the content of information, interrogation or command, in data exchange or transfer elements or modules.
A protocol can adopt and prescribe various operational rules and standardsxe2x80x94to which all physical connections with, and modes of communications over, the highway must defer, conform and adhere.
Thus, so-called SCSI and PCI, represent examples of common contemporary protocols for (parallel) bus configuration.
Bus
The term xe2x80x98busxe2x80x99 is used herein to embrace any form of communications channel, data highway or pathway, particularly, but not exclusively, of a parallel, or multiple simultaneous, channel or line character or configuration.
That said, aspects of the invention may be applicable to other, for example serial, bus configurations.
Generally, a bus is a transmission line, commonly expressed or embodied as a hardware signal path, of physical conductors, whether (umbilical) cables or printed circuit board (PCB) conductor strips.
As such, a bus could find diverse application from, say, vehicle electrical supply engine, transmission and brake monitoring and command multiplex wiring harness, through to personal computers.
Hardware aside, a bus could be interruptedxe2x80x94or even partxe2x80x94constituted byxe2x80x94intermediate radio, optical fibre or infra-red links, provided an electrical signal can physically be picked up at some point (eg of bus termination).
Interface
Interaction between a bus, a primary command and control processor or central processing unit (CPU) and a (peripheral) device is through an interfacexe2x80x94which itself must adhere to the bus protocol, but which enables physical (impedance or load) matching of otherwise incompatible elements, to allow converse therebetween.
The term xe2x80x98interfacexe2x80x99 is used herein to embrace an interconnection, principally by physical interaction, with a bus.
(Interface) ASIC
It is common to use a dedicated or bespoke (semiconductor) device configuration, such as an ASIC (Application Specific Integrated Circuit), in an interface between a bus and a peripheral device.
Such a xe2x80x98dedicatedxe2x80x99 ASIC is then instrumental in controlling interactions between a peripheral and the busxe2x80x94and, in particular, (when the protocol so allows) in a peripheral xe2x80x98assertingxe2x80x99 and xe2x80x98de-assertingxe2x80x99 temporary control over the bus, as discussed later.
Some aspects of the present invention are concerned with supplementing, enhancing or reinforcing the use of such an interface ASIC, with additional functionality and memory, intimately to address local conditions:
at the driver output of the ASIC; and
input of the ASIC.
Bus or Interface Protocol
A bus or interface protocol commonly embraces various features of hardware and software. As such, a protocol may dictate or prescribe signal levels, or ranges, and allocate particular significance to certain signal sequences, or combinations.
According to bus or interface configuration, the protocol may also allocate particular (control) functions to certain individual signal lines or channels, or select multi-channel combinations.
Generally, a given bus protocol prescribes intended or envisaged xe2x80x98allowablexe2x80x99, or correct, bus instantaneous signal level conditions, on individual bus lines.
However, the protocol may not be overly specific upon allowable departures from recommended or set levelsxe2x80x94and so upon what would constitute an xe2x80x98errorxe2x80x99 or fault condition, (and as such one in need of correction or resolution), as discussed later.
A protocol may also define signal level transitions, or changes, and sequences. Regard might also be paid to the cumulative or combinatorial effect of signal levels.
Some, but not all, protocols may allow different peripheral devices temporarily to take command and control over, or to xe2x80x98assertxe2x80x99 the bus.
Should an error or fault condition arise, as described later, it is important to know (in a bus which so allows) which (peripheral) device is asserting the bus at the time, in order to pin-point the source of xe2x80x98deviantxe2x80x99 behaviour.
Some form of local error monitoring capabilityxe2x80x94as provided by aspects of the present invention, discussed laterxe2x80x94is particularly advantageous when the protocol allows such peripheral device assertion.
Interrupt signals on the bus could preface hand-over and hand-back signal sequences, passing the bus over to other peripheral devices, or back to a centralised command CPU. Indeed in practice, in a computer system, the peripheral device(s) might well occupy more time cumulatively in charge of the bus than the CPU itself.
Hence the value of knowing which device is actively xe2x80x98assertingxe2x80x99 and which device(s) are xe2x80x98passivexe2x80x99 at any sampling instant. When not asserting the bus, a peripheral device is free to receive signals from, or to interrogate, signals upon the bus.
Generally, a device state will reflect signals detected on the bus, through an associated device interface.
In considering the interaction between a peripheral and the bus, separate or individual consideration must be given to:
the outflow of signal directivesxe2x80x94in a bus xe2x80x98assertionxe2x80x99 or driving mode; and
the inflow of signals from the busxe2x80x94in a passive reception or driven mode.
The passive mode is significant, since the peripheral can be commanded to change operational state or condition, in response to perceived bus signal changes.
Missed, or wrongly interpreted, bus signals can lead to a missed or skipped device state change and consequent disruption of device operational sequence in synchronism with the busxe2x80x94and attendant degradation in peripheral performance.
Physically, there is a unique common point or node location, from or at which both outgoing and incoming signals may be encounteredxe2x80x94for analysis of bus interactions and bus read-write errors associated with that peripheral.
A conventional self-contained bus analyser connected at a remote location (from the peripheral and its associated interface), simply cannot address or map that critical interface input-output node, which will enjoy an unique signal level profile.
Nor can a conventional bus analyser determine directly the operational state or phase of individual peripheral devices.
Thus bus signal conditionxe2x80x94upon which a conventional bus analyser is critically dependentxe2x80x94is not uniform throughout the bus. Nor is bus signal condition necessarily indicative, either of local interface signal condition (for any given peripheral), or of the operational state of that peripheral.
The diagnostic ability of a conventional bus analyser is thus constrainedxe2x80x94and inadequate for a complete diagnostic role.
Moreover, since a bus is effectively a transmission line, with inherent (characteristic) impedance losses throughout, it follows that relative xe2x80x98downstreamxe2x80x99 or xe2x80x98upstreamxe2x80x99 bus tappings cannot replicate a localised approachxe2x80x94as envisaged with aspects of the present invention. Nor can a remote bus analyser recognise state changes of individual peripherals.
Thus part of the performancexe2x80x94and thus errorxe2x80x94mapping is incomplete, and so potentially inadequate, in the conventional remote error signal capture and diagnostic approach.
As a transmission line, the bus access interfaces and terminations can prove critical. Thus bus loads must be matched to the bus transmission line characteristics, for effective signal energy transfer. Mis-matching can lead to spurious signal reflections or echoes and attendant interpretation errors and disruption. Matching an external bus analyser to a bus can be problematic.
The character or nature and extremity or degree of errors that can be tolerated by a bus protocol is not generally well-specified. Not all protocol interpretations by peripherals, or indeed the bus construction or CPU themselves, are uniformly consistent or xe2x80x98robustxe2x80x99.
It can be difficult to determine which errors will lead to total and non-recoverable bus failure and which to continual minor disruption, such as might trigger repeated automatic bus condition resets. Whilst a certain fault-tolerance can be built into the protocol, a tight or well-specified protocol may generally be less tolerant to errors or deviations from standard.
Deference to and compliance with protocol is a pre-requisite of stable performance. That said, departure or deviation from the protocol, however arising, disrupts data transfer and impedes performance of peripheral devices. Yet such irregularity can be difficult to identify. Moreover, with multiple inter-connected devices, the location of faults can be difficult to pin-point.
An interface standard, such as SCSI, requires a recognition of the current phase of the operational protocol and a knowledge of how to (re-)act accordingly, from current bus signals.
With multiple peripheral devices, (inter) connected through a common bus, differences in interpretation of the (say, SCSI) bus or interface protocol specification and consequently implementation of decision logic can cause problems.
Software aside, hardware problems can also arise from essentially physical factors, such as sporadic xe2x80x98glitchesxe2x80x99, unsatisfactory terminations or location of peripheralsxe2x80x94any of which can affect the perception of bus signals.
Testing and de-bugging tools, such as proprietary self-contained (SCSI) bus (interface) analysers, are typically employed to review system performance from xe2x80x98silicon turn-onxe2x80x99, through functional or product testing, to overall system integration.
In principle, by connection to the bus, such an analyser should act as a xe2x80x98passivexe2x80x99 observer, to capture information upon signal edge change or level transition and as such is useful in low level hardware and chip de-bugging.
However, protocol errors may well arise outside bus analyser testing. If the error has not been captured, it may at best be time-consuming to reproduce, or at worst non-repeatable.
Moreover, the very presence of the analyser on a bus can materially alter its physical characteristicsxe2x80x94potentially to the extent that an error problem may no longer be perceived. Yet that error condition may re-occur when the analyser is disconnected.
Indeed, it may prove difficult even to attach an analyser to a bus, without violating prescribed physical bus or (bus/interface offshoot or branch) stub length maxima.
Certain bus signal lines, such as those designated xe2x80x98BSYxe2x80x99 or xe2x80x98SELxe2x80x99, may be asserted by any peripheral following normal protocolxe2x80x94so the analyser cannot determine which peripheral is asserting bus signals in a fault condition.
Indeed, bus signal values perceived by an analyser on test mode reflect its (different) bus positioningxe2x80x94and so may not equate to that observed and interpreted by a (suspect) device.
Similarly, problems may arise on (customer) site, remote from diagnostic tools or expertisexe2x80x94and again it may not be possible to re-create themxe2x80x94with attendant customer dissatisfaction.
Thus, fault correction requires careful monitoring, analysis and interpretation. Errors can arise attendant physical device or inter-connection disturbances and mis-tracking of signal sequences, which can be independent or related.
SCSI is a particular example of a highly specific interface and bus protocol. SCSI configured peripheral devices include internal or external (in relation to a computer) hard disks, tape drives, CD-ROMS, printers, scanners etc.
According to one aspect of the invention, a bus and/or interface condition capture module, for integration or embedding in an interface between a command and data bus, such as a SCSI bus, and a computer peripheral device, is configured to serve as part of a bus analyser, the module comprising discrete memories for temporary storage of bus and/or interface signal condition and operational state or phase of the peripheral, for subsequent access, remote analysis and diagnosis.
The term analysis embraces interpretation and appraisal.
The memories may be configured as, say, RAM, or FIFO, with read-write modes adjusted accordingly.
The data captured includes both:
xe2x80x98correctxe2x80x99, (protocol) conforming or compliant; and
xe2x80x98incorrectxe2x80x99, non(protocol)-conforming, non-compliant, ie error or fault,
Signal Conditions and/or Operational States.
Such a capture module is conveniently incorporated in, or as an adjunct to, an interface ASIC, of a computer peripheral device, and configured to capture local bus and/or interface signal condition and operational state of the peripheral, for subsequent access, remote analysis and diagnosis.
In practice, the capture module could include a memory structured to store a history of bus signal transitions, and the assertion or de-assertion of signals, by the associated peripheral device, in whose interface the module is incorporated.
The invention embraces a peripheral device, with a bus interface incorporating a capture module.
The invention also embraces a computer, connected, through a bus, and peripheral interface, to a peripheral device, incorporating a bus and/or interface condition capture module.
According to yet another aspect of the invention, a method of bus and/or interface condition capture comprises the steps of separately monitoring criteria of bus and/or interface signal condition and operational state or phase of an associated peripheral device, and storing discretely changes in those criteria, for subsequent access, remote analysis and diagnosis.
According to a further aspect of the invention, a bespoke or dedicated bus and/or interface ASIC, is configured to incorporate, or work alongside, a localised bus and/or interface condition capture module, with discrete working memories, respectively for bus and/or interface signal condition and operational state or phase, of an attendant peripheral device, for onward relay to larger, longer terms storage, ready for subsequent access, remote analysis and diagnosis.
Both xe2x80x98correctxe2x80x99 or xe2x80x98incorrectxe2x80x99 signal levels or conditions and related or consequential peripheral operational states or phases could be recorded, continuallyxe2x80x94subject to occasional xe2x80x98flushingxe2x80x99 into a local RAM, under localised interface (eg ASIC) firmware control, ready for remote downloading or off-loading through bus ports, for devolved analysis and diagnosis.
If the peripheral is itself, or embodies, a large working memory, a portion could be allocated to the longer term (pre-diagnosis) retention of bus and/or interface condition and peripheral state.
It is envisaged that localisationxe2x80x94at a unique peripheral to bus interfacexe2x80x94of such a capture module would provide a more detailed and intimate record of interface conditions and associated peripheral state, than available hitherto from conventional stand-alone bus analysers.
In the short term, this facilitates diagnosis of machines away from a test laboratory, such as in customer hands. It would also allow the separation or isolation of error conditions arising from unique circumstances of customer environment or usagexe2x80x94such as power supply spikes. In the longer term, the error log should assist in xe2x80x98designing-outxe2x80x99 conditions leading to errors, or achieving greater resilience to error conditions, such as spurious noise.
In practice, the capture module could be implemented within, or alongside, an existing bespoke interface ASIC, with minimal disturbance to existing functionality. Nevertheless, the potential benefits could be (favourably) out of all proportion to the relatively modest implementation xe2x80x98overheadxe2x80x99 penalty.
The capture section or module records both bus signal levels drive signals initiated by the interface ASIC. The capture module memory required is relatively modest, as it is continually flushedxe2x80x94say, to a remote store, for analysisxe2x80x94and refreshed with more current bus condition data.
In one variant, the capture module memory is conveniently configured to a FIFO (first inxe2x80x94first out) operational store inventory mode.
Overall, the capture module effectively functions as a localised capture section of a xe2x80x98focussedxe2x80x99 bus analyser.
Capture operation is conveniently under control of firmware, which could detect occurrence of protocol error or bus/device resetxe2x80x94whereupon the bus condition data could be read into local processor memory, for subsequent remote extraction, over the bus itself, or through a bespoke diagnostic port or emulator interface.
Localisation of protocol error condition capturexe2x80x94through an interface ASICxe2x80x94obviates reliance upon failure mode repetition under contrived test conditions.
Absent this, full spectrum functional testing would otherwise entail a host of expensive analysers, in turn reliant upon statistical probabilities to catch failures for analysis.
With a peripheral device at a remote customer site, fault data from on-board capture modules can be downloaded electronically, using a software utility, to a diagnostic base. Without failure mode repetition, de-bugging is more readily undertaken.
The capture module stores a history of bus signal transitions, along with assertion/deassertion instances by the associated peripheral. This in turn facilitates isolation of peripherals generating protocol errors, and attendant de-bugging.
More particularly, the local capture module records xe2x80x98actuality of perception and reactionxe2x80x99 of the peripheral device under scrutinyxe2x80x94rather than a value perceived at a different bus position.